Presently, computer systems and the operation thereof are utilized in all facets of modern life. For example, computer systems are common both at home and in the workplace to increase productivity as well as provide user conveniences. Accordingly, there is a need for many different types of software to operate on computer systems. However, with the increased number and complexity of operating systems and the software operating thereon, the probability of technical errors and computer system crashes and/or failures has become increasingly likely. This trend has led to an increased emphasis on analysis of crash dumps to determine the root cause of a system failure.
When debugging parallel software systems postmortem (i.e., after the system has failed), it is often useful to know which mutually exclusive regions a given thread has access to (or had access to prior to system failure). The mutually exclusive regions correspond to regions that the thread enters by acquiring a mutual exclusion lock (“mutex”). Knowledge of the mutually exclusive regions that a thread has exclusive access to may provide insight into the state of the system at the time of the failure, and therefore aids analysis of the root cause of the system failure. For a given thread, the thread stack at the time the system failed may be inferred from the crash dump. From this thread stack, one may be able to infer the mutexes that the given thread should hold. The aforementioned approach typically requires a significant amount of computing power. Further, in some cases it may be difficult to infer which locks are held by a thread from the thread stack alone.
One way to determine which mutexes are owned by which threads is to log, in a global repository, the thread ID and lock address each time a thread acquires possession of a mutex and each time the thread releases the mutex.